前段时间技术调研有测试使用过。结果是果断弃用，原因如下

1，杂而不精

咋说呢，妄想一口气吃下多个平台，结果就是搞出了个不伦不类的东西。要说有用吧！小项目确实有用，有封装好一些SDK，可以简化一些开发流程，但如果想要做高度定制，别想了。

难以理解的是，作为开发者工具的 HBuilderX 里边，居然有广告，居然有广告，居然有广告……

真是离了大谱，第一次在开发者工具里边看到招聘广告的。

2，不伦不类

再一个不能理解的是，uni app主要目标使用群体是前端，但似乎却在打造一个独有的跟前端割裂的生态，无论是官方的开发模式，还是一些插件加载等，很多跟前端开发流程不匹配。无论是 HbuilderX，还是自定义的插件商店而不是 npm 等

后来仔细一想，可能目的是为了简化项目结构，可这种简化个人觉得没这个必要。

3，文档混乱

由于为了宣传的支持多平台，文档中接口也为了做到统一，所以经常会看到这样的情况：

再然后，就是很多 uni app 自己都解决不了的问题，告诉你，这个我也没办法，给你几个建议你自己看着办吧之类的文档

4，对App 开发没什么大的作用

刚开始很好奇，uni app 是用了什么黑科技，即能支持 小程序，又能支持 app，抱着仰慕学习的态度做了这次技术调研，发现这东西不就是把多个平台拼凑了起来嘛！论好的一点，就是将各个平台的api做了统一，这一点是值得肯定的。但是为了做到这个目的，也让各个平台的环节比较薄弱。这一点就是 1 中所说的杂而不精。

相对来讲，对于小程序这种相对简单的平台来讲，uni 是可以胜任的，甚至是有一定优势的（多个平台），但在 App 方面，就毫无优势可言。

uni 提供了两种 App 渲染模式，一种是 基于 weex 的 .nvue, 一种是 基于webview 的 .vue。对于后者，实际上还有一个类似的平台：apicloud，这俩平台很类似，都是给 webview提供常用的接口，让 h5页面具备调用系统api能力。区别在于 uni 使用了vue而已。

所以，如果只是采用 vue 来开发，所开发的app实际上就相当于 h5 套壳，如果可以的话，完全可以把app做成一个h5网站，用定制webview 来像浏览器一样加载使用。所以，这一类的app注定性能是没法跟原生的比的

而如果 使用 .nvue，则使用的是 weex, 这个方案相对于 React Native 是没什么优势的，甚至已经停止维护了。如果采用 nvue 模式开发，意味着有很多无人来填的坑……。亲测 nvue 确实不太好用，很多组件使用起来，有莫名其妙的问题。

而如果 采用 nvue, vue 这两种模式混合开发，又有其它的问题。比如，一个公共组件，可能得写两个，一个用于 webview 模式引用，一个用于 weex 模式引用。在考虑到 android ios 兼容性问题，可能得写三个，徒增复杂度。

综上所述，个人觉得 uni 对于 App 开发绝对不是一个好的方案。只能用于较为简单的项目。做大一点的也可以，可成本要远远高于所预期的